InfoMagic Standards 1994 January

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / misc / merit / noop / tutorial / intop91.les < prev next >

Wrap

Text File | 1992-01-20 | 28KB | 681 lines

Lessons Learned for OSI at INTEROP 91 By Susan Hares -- MERIT/NSFNET Thirty networking technology vendors worked together to provide a demonstration of OSI applications and network protocols over the internet's Infrastructure for INTEROP 91. The National Agency networks participating in this event were NSFNET, ESNET, and NASA. This demonstration linked workstations on the convention show floor with workstations in Europe, the United States and Australia (see figure 1). This INTEROP 91 demonstration showed how co-operation from many network service providers and vendors can make OSI applications over the internet a reality. The lessons learned from this demonstration pave the way for continuing OSI traffic in the internet. One of the most valuable lessons from INTEROP 91 was that we can make OSI work in the internet. OSI vendors who participated in the OSI demonstration want to continue to use the internet during the next year. The most painful lessons at INTEROP 91 were the obstacles to showing the OSI applications. The OSI Demonstration booth encountered three types of problems: - problems setting up the physical network, - problems setting up and debugging a multi-protocol network, and - problems configuring OSI routers and debugging OSI related problems. Setting up a huge multi-protocol network in days is close to impossible. Only extensive planning and testing, and excellent co-operation from internet community (vendors and network service providers) has allowed INTEROP to accomplish this difficult task year after year. Every booth encountered some problems due to the physical network set-up and multi-protocol network debugging. These types of problems are normal when setting up something like the INTEROP show floor. In addition, the OSI Demonstration booth encountered problems due to: - problems with the set-up of OSI routing of Connectionless Network Layer Protocol (CLNP) packets via static configurations, and - lack of OSI network debugging tools on every machine. Sometimes OSI application traffic flowed from the show floor to Europe, but not between booths at the show floor. figure 1 - OSI Infrastructure in the Internet (picture available for anonymous ftp in the file lesson.01.ps on merit.edu in the directory /pub/iso/noop/tutorial) 1 What Happened at INTEROP 91 ---------------------------- OSI demonstrations on the INTEROP 91 show floor included OSI Vendor booths and the collaborative OSI Demonstration booth (see figure 3). ISO's End System to Intermediate System (ES-IS) protocol was used between multiple hosts (end system) and routers (intermediate system) from many different vendors. ISO's Intermediate System to Intermediate System (IS-IS) protocol was demonstrated in the OSI Demonstration booth. IS-IS is an ISO intra-domain routing protocol which is similar to Internet Gateway Protocols (IGPs) in the IP suite. NSFNET has used an implementation of the IS-IS routing protocol adapted for IP since 1988. The OSI applications demonstrated at the OSI demonstration booth and Vendor booths included four major OSI applications: X.400, File Transfer Access and Management (FTAM), Virtual Terminal (VT), and X.500. X.500 was demonstrated over both IP and CLNP showing that OSI applications do not have to be limited to OSI lower layer stacks. Figure 2 shows Internet applications which have some of the functions of these four major OSI applications. OSI application Internet Application(s) with some of the same functions =================== ====================== VT telnet FTAM ftp X.400 SMTP X.500 none *1 Note: *1 - The TCP/IP protocol suite has no protocol that provides the distributed directory service that X.500 provides. X.500 is being used over TCP/IP in the internet. Figure 2 - OSI applications compared to TCP/IP applications A prototype of the ISO Inter-Domain Routing Protocol (IDRP) was demonstrated. IDRP provides a means of passing OSI routing information between domains and applying policy filters to that routing information. An IP protocol which provides the some this functionality for IP is the Border Gateway Protocol (BGP). The IDRP protocol is in the second stage of the development process as an ISO standard. The development of the IDRP prototype provided a great deal of feedback on this ISO standard (CD 10747) to the US committee working on this standard. T h e I D R P prototype passed traffic between the nodes in the OSI 2 demonstration booth, the IBM booth, and nodes on the ANS/NSFNET T3 test network. The IDRP protocol was developed by Dave Katz of Merit, and further details can be obtained from Merit. figure 3 - OSI at INTEROP 91 (figure available for anonymous ftp on merit.edu on the directory /pub/iso/noop/tutorial/lesson.03.ps Lesson 1 - People make OSI Work Many talented people made the OSI Infrastructure demonstration happen. I am convinced that the internet networks work and advance because talented individuals push and push until the network technology advances. Companies support technology advances by putting the punch behind their people. Cyndi Jung (3COM) helped me organize the OSI demonstration booth and internet testing. She spent countless hours working on the OSI Hot Stage and the Backbone Hot stage. The router vendors (cisco Systems, Proteon, 3COM, Wellfleet, Network Systems, DEC) spent extra time helping out the internet, Hot Stages and IS-IS testing. Two especially hard workers were Paulina Knibbe (cisco) and Ed Stern (Proteon). End system vendors worked with Network service people to set-up the OSI application demonstrations. Night after night Charlie Alberts (Banyan), John Davis (Banyan), Kevin Jordan and others from CDC, Eva Kuiper (HP), and other vendors tested FTAM, X.400 and X.500 across the internet. Cathy Wittbrodt, Arlene Getchell, Tony Genovese of ESNET made the ESNET networks and OSI applications work. Juha Heinanen and lots of people from the RARE-WG4 CLNS project helped connect Europe to this demonstration. Linda Winkler (Argonne Labs), Alan Clegg(CONCERT), Mark Knopper (MERIT), Walt Lazear (MITRE) and John McGuthry (MITRE), Doug Montgomery (NIST), Cathy Fouston (Sesquinet) and Bill Manning (Sesquinet) got more OSI Applications working across the internet. The roll call for the network path includes many of the people who make IP a reality today: Vince Fuller and Ron Roberts (BARRNet), Mark Oros (ICMNet), Tim Salo and Jeff Wabik (Minnesota Super Computer), John Curran (NEARnet), Dave O'Leary (SURANet) and Andrew Partan (UUNET). Some of the networks companies that lent their people, equipment and push to the OSI infrastructure demonstration included: Alcafel TITN, 3COM, ANS, Argonne National Laboratory, AT&T, Banyan, BARRNet, CERFNET, CERN, CICNET, cisco, Control Data Corporation, CONCERT, Digital Equipment Corporation, ESNET, Frontier, HP, IBM, ICMNet, INFN (Italy), networks in Spain, 3 networks in Germany, MERIT, MIDNET, MITRE, Minnesota Supercomputer Network, MRnet, NASA Science Network, NorduNet, NEARnet, Network Systems, Novell, NIST, OSINET, Pyramid, RETIX, SURANet, SWITCH (Switzerland), Tandem, UNISYS, UNISYS-Australia, Wallongong Group, and Westnet. One thing that helped harness these people were numerous conference calls provided by MCI. Lesson 2 - Build on the Past The OSI Infrastructure demonstration is the culmination of years of work. The idea for the Infrastructure demonstration was conceived in mid June of 1991 as a milestone for the long term work in the US internet. The extension of OSI application traffic to some 30 networking technology vendors over a good portion of the internet took place within 3 months. The rapid deployment of this Infrastructure was due to: - past work in OSI by Pilot Projects in Europe and the US, and - outstanding work by each of the networks and companies participating in the demonstration. The OSI support in routers and End systems has matured a lot in past year. The Pilot projects in European and the US have caused some of these products to mature. These Pilot projects have tested products, reported bugs, and suggested improvements to user interfaces and product capabilities. Pilot Project History --------------------- The NSFNET demonstrated a prototype implementation of the Connectionless Network Protocol (CLNP) at INTEROP 89 in September of 1989. The T1 NSFNET has been capable of routing Connectionless Network Protocol (CLNP) since August of 1990. During August of 1990, MERIT exchanged CLNP packets with sites in Europe as part of a Pilot project involving European Pilot Project sites and the NSFNET. During INTEROP 90, CLNP packets were exchanged between systems on the show floor systems in Europe which were a part of the European RARE-WG-4 CLNS Pilot Project. During the time period between October 1990 and April 1991, MITRE and other US companies exchanged information using OSI applications (FTAM and X.500) with systems in Europe participating in this European RARE-WG-4 CLNS Pilot project. In April of 1991, two US sites - Merit and MITRE - successfully sent files between US systems on the internet over a pure OSI stack using the CLNP for the network layer protocol. The network 4 pathway between these hosts was set up with the help of MichNet, UUNET, and NSFNET. These OSI hosts at MITRE and MERIT transferred several files. Energy Science Network (ESNET) has been working toward providing OSI within its backbone since early 1991. During the June of 1991, ESNET was capable of routing CLNP packets to several of the sites within ESNET. By September, ESNET could route CLNP packets in all routers on ESNET's backbone. By October 1991, several ESNet Sites had hosts which exchanged information using OSI applications (FTAM, X.400, X.500) over the pure OSI stack using this CLNP pathway. Lesson 3 - Test Everything You Can The Testing for the OSI demonstration booth was continuous from mid-June (when the idea was conceived) until INTEROP 91. While two Hot Stages were involved in this testing, most of the network testing for the OSI Infrastructure demonstration took place outside of the Hot Stage time periods. The following testing was done: a.) pre-Hot Stage internet Set-up and Tests b.) NIST IS-IS test Lab c.) OSI Hot Stage d.) backbone Hot Stage e.) internet Testing of Applications All of this testing took time, but pointed out the need for an on-going test bed. The IETF (Internet Engineering Task Force) Network layer OSI OPerational (NOOP) working group will be investigating how to organize a test bed for OSI. This test bed needs to have all routers running CLNP, and IS-IS within some routers. This national test bed needs to have end systems actively running OSI applications. Pieces of this test bed need to be linked together using the production internet. OSI applications need to run between systems on the test bed as well as systems off the production internet. Problems on operational networks can be reduced by putting new router software into test bed nodes, and passing OSI and IP application traffic over these routers. A continual testing of router and application software will lessen the time needed for INTEROP testing. An added benefit of a national test bed is that additional demonstrations of OSI applications over the internet could be staged quickly. Pre-Hot Stage Internet Set-up and Tests 5 --------------------------------------- Setting up each internet connection to a site running an OSI application took the following steps: step 1 - Get the permission of one or more of network service providers to pass CLNP packets. step 2 - Set up routers in the networks to route CLNP packets. step 3 - Set-up OSI applications on hosts. step 4 - Test OSI applications over these networks. During June, July and August a great number of the sites on the internet followed these four steps and got OSI application traffic flowing across the internet. NIST testing of IS-IS ----------------------- The National Institute of Standards and Technology (NIST) hosted a week of pre-INTEROP 91 dynamic router interoperability testing August 12-16. The open lab was part of NIST's Cooperative Laboratory for OSI Routing Technology program. Testing addressed the Draft International Standard specification of the IS-IS protocol (DIS 10589) and the operation of the IS-IS protocol in a live multi-vendor Intermediate and End System environment. OSI routing was tested over Ethernet. Vendors participating in the IS-IS testing included 3COM, Digital Equipment Corporation, Proteon and Wellfleet. This testing allowed the OSI Hot Staging to use the IS-IS protocol to support OSI applications. Breaking off routing protocol testing from OSI application testing greatly improved the OSI Hot Staging efforts. OSI Demonstration Booth Hot Staging ----------------------------------- During the last week of August 1991, a "hot stage" was held for the OSI demonstration booth. A T1 link from BARRNET to the OSI Hot Stage was essential for the success of the testing between vendors and OSI infrastructure demonstration. Full fledged internet access allowed the vendors to exchange mail and obtain software changes from their company. Due to the full fledged internet access not all team members working on an OSI product needed to attend the hot stage. Several experts from OSI vendors used the internet to login to "hot stage" systems. Without leaving his/her desk at work, an expert could examine problems and try out solutions. Companies provided expertise without the cost of sending an additional person to the "hot stage". Application traffic for the OSI Infrastructure demonstration flowed across the T1 link to BARRNET. Due to this T1 link, Infrastructure demonstration through out the internet could be 6 debugged from the "hot stage" area. Backbone Hot Stage -------------------- INTEROP 91 Backbone Hot staging started during the last week of August and continued through-out September. The backbone hot stage had the challenging task of putting IP, OSPF, CLNP on interfaces with FDDI, serial lines, ethernet, ISDN. Most networks only use a fraction of these protocols. The combination of these protocols in a multi-vendor environment broke new ground. The backbone "Hot Staging" showed that not only OSI, but other protocols can benefit from a national test-bed for router software. Another lesson from the Backbone Hot Staging is the need for good internet connectivity to any "Hot Stage" activity. During the early stages of the Backbone Hot Staging, the internet connection was not a full T1 link. Without this T1 link to the Hot Staging, access to Internet resources for exchange of mail or code updates was slow and problems took longer to fix. Experts from router vendors could not quickly access the routers backbone staging from their desk as they could with the OSI "hot stage". Lesson 4 - OSI addressing needs full X.500 service Keeping up with the changing OSI addresses for each router and end system was quite a chore. The X.500 work for placing network addresses or host addresses in a global X.500 directory is not complete. While there is progress being made on these issues in several pilot projects, most of the addresses for the routers and end systems for INTEROP 91 were kept in files. Managing these files took a great deal of my time, and needs to be improved for future internet work. An interim place to register network addresses and OSI application addresses needs to be in place while X.500 work continues. As a result of the INTEROP 91 work, the mail group osi-pilot@merit.edu will help work with this address nightmare. Router and end system vendors use different formats to express network address (Network Service Access Point (NSAP) addresses) and OSI application addresses. A common format for expressing these addresses would greatly speed debugging of network problems. Network debugging tools would only have to function on one format, not several. Lesson 5 - Routing Protocol (IS-IS) is much better than Static configurations The OSI Demonstration booth ran IS-IS between routers within the 7 booth, BARRNEt, and 3COM. The IS-IS routing protocol handled loss of links, and automatically switched to a backup route. The routers involved in the IS-IS protocol (3COM, Proteon, and Wellfleet) passed lots of traffic to the internet. The INTEROP 91 show floor backbone routers ran static route configurations for CLNP. While the software on the routers running these static configurations ran well, setting up these configurations for the large show network was difficult. The lessons the internet at large has learned about static routes for IP were re-learned as we tried to use static routes for OSI. The worst stress on static routes came when the INTEROP show floor team changed router vendors for some the show floor routers (due to non-OSI protocol issues) on the day before the show opened. This last minute change required a re-doing a lot of OSI static routing configurations in the new vendors routers on within hours of the when the INTEROP 91 show. Even with improved tracking of router configurations by the show floor NOC, the sheer amount of static configurations made life difficult for the show floor network. In fact, some problems in booth to booth connections were caused by human errors in static configurations. In contrast, the show floor configurations for the internet were only a few entries. Since OSI routing allows many network addresses to be summarized by a shorter address string (or network prefix), the static configurations for the internet were few (2-4) and of short length (1-2 octets). The use of IS-IS within the show network would greatly reduce the amount of effort needed to support OSI traffic within the show network. Since INTEROP 91, NASA Science network has employed OSPF for IP and IS-IS for OSI. NASA Science network added IS-IS to it's network running OSPF and encountered few problems. Using IS-IS for INTEROP 92 seems within today's technical reach. Lesson 6 - The Challenge of the INTEROP Show Floor has Grown Success in networking is the best of all times and the worst of all times. The INTEROP show floor has grown from a few machines hooked together by 2 or 3 routers on an ethernet to a network spanning all possible technology with over 25 backbone routers. What networks grow over months, INTEROP 91 tried to do in 3 days. The OSI demonstration encountered the problems you would expect in such an environment. The physical and logical connections within the booth and to the outside needed to be made prior to any network testing. Little things like power coming in a few hours behind the schedule become critical in this compressed time schedule. Demonstrations which expect to work in all three areas: within a booth, between booths, and between the booth and 8 sites on the Network need every second of testing time. Also, in an Infrastructure or internet wide demonstration a large number of people are needed to solve a problem. A great deal of scheduling needs to take place to allow quick debugging. The network connection needs to be ready at least a full day in advance of the show floor opening to give an Infrastructure demonstration time to check out the demonstration. The INTEROP 91 OSI demonstration uncovered a need for improvement in the show floor scheduling and debugging. Infrastructure debugging sessions were scheduled and dismissed due to the lack of network connectivity. The final OSI link to the internet came up within an hour of show time. Fortunately, due to lots of pre- testing, most things worked. But an hour is just not enough time to fix any problems. Several excellent volunteers helped set-up INTEROP 91. People who know how to set-up IP networks worked long and hard on the show floor network. Was it the static configurations for OSI that slowed the network set-up down? Was it sheer amount of physical set-up? Was it lack of wide spread knowledge of OSI? Was it the last minute switch of router vendors for some of the show floor routers? Was it something else? Improvement is needed for INTEROP 92. One improvement OSI vendors need to make is a common set of network tools. Network tools include an OSI ping, an OSI traceroute, and a listing of OSI network routing tables. While we expect these functions to work across all IP hosts and routers, this functionality is not available on every OSI host. Most OSI routers provide these network tools. However, not all OSI pings and traceroute interoperate between routers. As a result of INTEROP 91 the IETF Network layer OSI OPerational (NOOP) group is preparing an RFC on OSI network tools. Lesson 7 - IP versus OSI - Are we learning or emoting? The friendly competition between IP and OSI has strengthened both protocol suites. The strength of IP and the internet has been the "make it work" attitude. The ISO protocols are agreements between many nations. Both groups have something they can learn from the other protocol suites' successes and failures. When this friendly competition and bantering gives way to unthinking emotional arguments, we all cease learning. While working on INTEROP 91, I saw people with IP backgrounds learn how to make OSI work in their networks. To my delight, people from OSI backgrounds or companies learned a lot about the internet and IP. Sadly, I also witnessed some of the most close minded emotional arguments about OSI and IP. I salute those IP people who took time to strengthen IP by learning about OSI. I salute those OSI people who made OSI stronger by learning about IP and 9 the internet. I suppose as always, this INTEROP was the best of all times and the worst of all times. 10